Systems and methods for utilization of anycast techniques in a dns architecture

ABSTRACT

Aspects of the present disclosure involve systems, methods, computer program products, and the like, for utilizing multiple anycast addresses within a domain name system (DNS) architecture of a CDN. one or more DNS servers of the architecture may announce a plurality of anycast addresses for receiving DNS requests from requesting devices. The group of addresses may be dispersed (and/or announced by) the DNS servers of the architecture such that each server announces a subset of the available addresses. The number and identity of the subset of available anycast addresses utilized may vary from server to server of the DNS architecture and may be determined based on groups of servers, configurations of metros or gateways of the DNS architecture, or performance metrics of one or more servers.

TECHNICAL FIELD

Embodiments of the present invention generally relate to systems andmethods for implementing a content distribution network (CDN), and morespecifically for utilizing multiple anycast addresses within a domainname system (DNS) architecture of a CDN.

BACKGROUND

The Internet and the World Wide Web (the “Web”) are ubiquitous andeasily accessible using numerous possible wired or wireless computingdevices. Content providers (publishers) now use the Internet (and,particularly, the Web) to provide all kinds of content to numerous usersthroughout the world through any number of platforms. In order tooffload the job of serving some or all of its content, many contentproviders now operate or subscribe to content delivery networks (CDNs).Provider content can be served to clients from the CDN (i.e., from oneor more content servers in the CDN) instead of from the contentprovider's server(s). In a caching CDN, content may also be cached onsome or all of the CDN servers, either before being served or inresponse to specific requests for that content. Having content cachedenhances the performance of the CDN because the content does not have tobe retrieved from origin servers or other locations, which are lessefficient than edge servers in providing content.

Numerous forms of content may be served from the CDN. For example,television shows and movies may now be accessed from any number of Websites, and the shows and movies may be served from the CDN. Printnewspapers have migrated to the Web and provide portals through whichclients operating some form of computing device (e.g., PC, smart phone,or tablet), with a browser may access numerous forms of content, such asshort video clips, articles, images, and audio tracks. Software updatesand patches, once provided on disc and mailed to recipients, are nowroutinely distributed to devices from a CDN through one or more networkconnections and devices.

CDNs typically include a domain name server (DNS) architecture tosupport the distribution of content from the CDN to a requesting deviceor user. In general, the DNS architecture includes multiple DNS serversthat, in response to a request, return an Internet Protocol (IP) addressor other device address at which requested content may be downloaded. Insome instances, the DNS architecture may return several delegated DNSserver addresses (or nameservers) from which more information to resolvethe DNS request may be provided. However, the quantity of nameserversthat may be returned in response to the DNS request may push the limitsof scalability within standard internet DNS capabilities. As a result,new approaches for DNS network traffic management and DNS requesthandling have been developed, including utilizing load balancing andanycast techniques in an effort to reduce the size of results providedby the DNS system.

It is with these observations in mind, among many others, that aspectsof the present disclosure were conceived and developed.

SUMMARY

One approach may include the use of anycast-based DNS where one DNS“server” IP address is actually assigned to more than one server,letting Internet protocol (IP) routing carry the traffic to the bestlocation. Another approach disclosed herein implements load balancerswithin a gateway to provide similar functionality.

This disclosure proposes, among other things, the use of multipleanycast addresses to address some common problems with anycast design.For instance, a router or device may blackhole some traffic. There isalso a need for monitoring of the anycast addresses and automaticannouncement and withdrawal of the IPs

One implementation of the present disclosure may take the form of amethod for processing domain name system (DNS) requests. The method mayinclude announcing, by a DNS server of a plurality of DNS servers andbased on a configuration of the plurality of DNS servers, a subset of aplurality of anycast Internet Protocol (IP) addresses associated with aDNS network, the DNS server configured to receive a DNS requestcomprising at least one of the subset of the plurality of anycast IPaddresses, receiving, at the DNS server and from a networking device,the DNS request comprising the at least one of the subset of theplurality of anycast IP addresses, and generating a response to the DNSrequest.

Another implementation of the present disclosure may take the form of adomain name system (DNS) architecture. The system may include anetworking device and a plurality of DNS servers each in communicationwith the networking device. The at least one of the plurality of DNSservers configured to announce, based on a number of the plurality ofDNS servers to the networking device, a subset of a plurality of anycastInternet Protocol (IP) addresses associated with the DNS architecture towhich one or more DNS requests for the DNS architecture are addressed,receive, from the networking device and based on at least one of theannounced subset of the plurality of anycast IP addresses, a DNS requestcomprising the at least one of the announced subset of the plurality ofanycast IP addresses, and generate a response to the DNS request.

Yet another implementation of the present disclosure may take the formof a communications network comprising a first metro network comprisinga first networking device and a first plurality of DNS servers each incommunication with the first networking device. The communicationsnetwork may also include a second metro network geographically separatefrom the first metro network and in communication with the first metronetwork, the second metro network comprising a second networking deviceand a second plurality of DNS servers each in communication with thesecond networking device. At least one of the first plurality of DNSservers and at least one of the second plurality of DNS servers areconfigured to announce a subset of a plurality of anycast InternetProtocol (IP) addresses to which one or more DNS requests are addressed,receive, from a corresponding networking device and based on at leastone of the announced subset of the plurality of anycast IP addresses, aDNS request comprising the at least one of the announced subset of theplurality of anycast IP addresses, and generate a response to the DNSrequest.

Among other things, this disclosure proposes changes to conventionalsystems to facilitate such functionality. It should be noted that to theextent any particular network addresses, subnet, ports, or otheridentifiers are included in this disclosure, such identifiers are merelyexamples and any other suitable identifiers may be used inimplementations of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is an example network environment for distributing content over atelecommunications network.

FIG. 2 is an example network environment of an authoritative domain nameserver (DNS) of a DNS architecture.

FIG. 3A is an example network environment for utilizing an anycastaddress for multiple DNS servers.

FIG. 3B is an example network environment for utilizing a plurality ofanycast addresses for multiple DNS servers.

FIG. 4A is an example network environment for utilizing an anycastaddress for multiple DNS servers within the same metro.

FIG. 4B is an example network environment for utilizing a plurality ofanycast addresses for multiple DNS servers within the same metro orgateway.

FIG. 4C is an example network environment for utilizing a plurality ofanycast addresses for multiple DNS servers within the same metro bysplicing the plurality of anycast addresses across the multiple DNSservers.

FIG. 5A is an example network environment for utilizing a plurality ofanycast addresses for multiple DNS servers within multiple metros orgateways.

FIG. 5B is the example network environment of FIG. 5A limiting anycastaddresses for a metro of the multiple metros.

FIG. 5C is the example network environment of FIG. 5A in response to oneor more overload conditions at one or more of the multiple DNS serversby announcing one or more preferred anycast addresses.

FIG. 5D is the example network environment of FIG. 5A limiting one ormore anycast addresses for the multiple metros.

FIG. 6 is the example network environment of FIG. 5A, with each of themultiple DNS servers advertising a unique anycast address to monitor theserver performance.

FIG. 7 is a flowchart of a method for utilizing a plurality of anycastaddresses in a DNS architecture of a CDN.

FIG. 8 is a diagram illustrating an example of a computing system whichmay be used in implementing embodiments of the present disclosure.

FIG. 9 is an example network environment for utilizing one or more loadbalancer devices in a DNS architecture.

FIG. 10 is a flowchart of a method for a load balancer to activelymonitor each of the other load balancers in a metro or group.

DETAILED DESCRIPTION

Aspects of the present disclosure involve systems, methods, computerprogram products, and the like, for utilizing multiple anycast addresseswithin a DNS architecture of a CDN. In general, one or more DNS serversof the architecture may announce a plurality of anycast addresses forreceiving DNS requests from requesting devices. Anycast routing is arouting methodology in which a single destination Internet Protocol (IP)address is announced by multiple devices of a network such that multiplerouting paths are available for a communication. Routers select adesired path to the destination device based on number of hops,distance, lowest cost, etc. A DNS architecture may utilize and announce,in one example, a group of 16 IP anycast addresses for receiving DNSrequests. The group of addresses may be dispersed (and/or announced by)the DNS servers of the architecture such that each server announces asubset of the available addresses. In this manner, the group of IPaddresses for the DNS architecture may be referred to as “anycast”addresses as each address may identify more than one server in thearchitecture. The number and identity of the subset of available anycastaddresses may vary from server to server of the DNS architecture and maybe determined based on groups of servers, configurations of metros orgateways of the DNS architecture, performance of one or more servers,and the like.

In some implementations, each server (in a group of servers) of the DNSarchitecture may announce a plurality of anycast addresses (instead of asingle address) to other network devices to load balance DNS requestsacross the group of servers. Although some routers may include a loadbalancing feature for providing communications with an anycastdestination address across the multiple servers, such load balancing isoften limited to only a certain number of servers. Through the use ofanycast addresses and, more particularly, spreading a group of anycastaddresses across a group of servers such that each server announces asubset of the available anycast addresses, load balancing of DNSrequests may occur across all of the servers in the group. In anotherexample, a metro or gateway network configuration of the DNS network mayinclude multiple routers in addition to the multiple DNS servers.Through the use of multiple anycast addresses, DNS requests may bespread across each server of the metro. In one particular example of aDNS architecture, the group of anycast addresses used by thearchitecture may be sliced among the servers of the metro (such thateach server announces a portion or subset of the group of anycastaddresses) to balance the requests among the servers. The use ofmultiple anycast addresses further provides for redirection of DNSrequests to other servers within the metro in cases of server failure oroverload conditions at a server of the metro.

Multiple anycast addresses in a DNS architecture also provides for loadbalancing and redirection of requests among multiple metros or gatewaysof the DNS network. For example, through the announcement and retractionof subsets of the group of anycast addresses for the DNS architecture,servers and/or routers of the DNS network may direct DNS requeststo/from particular metros of the network to other metros of the network.Such redirection of DNS requests may occur in response to a detectedoverload condition at one or more servers of a metro and may be returnedto the one or more servers when the overload condition is removed.Further, each router or server of the network may be configured toannounce at least one of the group of anycast addresses such that eachserver is available to respond to DNS requests associated with the atleast one anycast address. The determination of the subset of anycastaddresses that each server of the architecture announces may be based,in one implementation, on a hashing function executed by each serversuch that a centralized controller may not be implemented in thearchitecture or network. As such, the servers and routers of the DNSarchitecture or configuration may utilize a group of anycast addressesto provide load balancing, overload response, and traffic managementacross each of the servers or metros of the DNS architecture to improvethe response to DNS requests received at the architecture.

Other implementations are also described and recited herein. Further,while multiple implementations are disclosed, still otherimplementations of the presently disclosed technology will becomeapparent to those skilled in the art from the following detaileddescription, which shows and describes illustrative implementations ofthe presently disclosed technology. As will be realized, the presentlydisclosed technology is capable of modifications in various aspects, allwithout departing from the spirit and scope of the presently disclosedtechnology. Accordingly, the drawings and detailed description are to beregarded as illustrative in nature and not limiting.

FIG. 1 is an example network environment 100 for distributing content toone or more users. Although illustrated in FIG. 1 as a content deliverynetwork, it should be appreciated that aspects of the present disclosuremay apply to any type of network that utilizes network addressing (suchas Internet Protocol (IP) addresses, media access control (MAC)addresses, domain names, etc.) for connecting an end user to one or morecomponents of the network. For example, aspects of the disclosure may beutilized to connect a user of the network to a content server on whichone or more content files is stored. Thus, although the CDN architectureis used throughout the document as the example network architecturethrough which aspects of the present disclosure may be applied; othernetwork architectures and configurations are similarly contemplated.

In one implementation of the network environment 100, a CDN 102 iscommunicably coupled to one or more access networks 106. In general, theCDN 102 comprises one or more components configured to provide contentto a device upon a request. The CDN may also include an underlying IPnetwork through which the request is received and the content isprovided. The underlying IP network associated with the CDN servers maybe any type IP-based communication network configured to transmit andreceive communications through the network and may include any numberand types of telecommunications components. In this manner, CDN-basedcomponents may be added to an existing IP-based communication networksuch that the components receive a request for content, retrieve thecontent from a storage device, and provide the content to the requestingdevice through the supporting IP network. For simplicity, the use of theterm “CDN” throughout this disclosure refers to the combination of theone or more content servers and the underlying IP network for processingand transmitting communications, including one or more domain namearchitectures, unless otherwise noted.

In one embodiment, a device 104 connects to the CDN 102 through one ormore access networks 106 to request and receive content or content filesfrom the CDN. The access network 106 may be under the control of oroperated/maintained by one or more entities, such as, for example, oneor more Internet Service Providers (ISPs) that provide access to the CDN102. Thus, for example, the access network 106 may provide Internetaccess to a device 104. In addition, the access network 106 may includeseveral connections to the IP network of the CDN 102. For example,access network 106 includes access point 120 and access point 122. Also,the device 104 may be connected to any number of access networks 106such that access to the CDN 102 may occur through another accessnetwork. In general, access to a CDN 102 (or underlying IP networkassociated with the CDN) may occur through any number of ingress portsto the CDN through any number of access networks.

The CDN 102 is capable of providing content to a device 104, which isgenerally any form of computing device, such as a personal computer,mobile device, tablet, smart TV, or the like. Content may include,without limitation, videos, multimedia, images, audio files, text,documents, software, and other electronic resources. The device 104 isconfigured to request, receive, process, and present content. In oneimplementation, the device 104 includes an Internet browser applicationwith which a link (e.g., a hyperlink) to a content item may be selectedor otherwise entered, causing a request to be sent to a directory server110 in the CDN 102.

The directory or authoritative server 110 responds to the request byproviding a network address (e.g., an IP address) where the contentassociated with the selected link can be obtained. In oneimplementation, the directory server 110 provides a domain name system(DNS) service, which resolves an alphanumeric domain name to an IPaddress. The directory server 110 resolves the link name (e.g., URL orother identifier) to an associated network address from which the device104 can retrieve the content. In some instances, the access network 106may also include a DNS service. The directory server 110 may, in someinstances, include several DNS servers arranged in a DNS architecture orsystem of servers to resolve domain names into IP addresses. Theoperation of the directory system 110 and access network 106 to resolverequests for content from the device 104 is discussed in more detailbelow with reference to FIG. 2.

In one implementation, the CDN 102 includes an edge server 112, whichmay cache content from another server to make it available in a moregeographically or logically proximate location to the device 104. Theedge server 112 may reduce network loads, optimize utilization ofavailable capacity, lower delivery costs, and/or reduce content downloadtime. The edge server 112 is configured to provide requested content toa requestor, which may be the device 104 possibly via an intermediatedevice, for example, in the access network 106. In one implementation,the edge server 112 provides the requested content that is locallystored in cache. In another implementation, the edge server 112retrieves the requested content from another source, such as a mediaaccess server (MAS) (e.g., a content distribution server 114 or acontent origin server 116 of a content provider network 118). Thecontent is then served to the device 104 in response to the requests.

FIG. 2 is an example network environment of an authoritative domain namesystem (DNS) of a DNS architecture. The components of the network 200are similar or the same as components discussed above with reference tothe network 100 of FIG. 1. For example, the network environment 200 ofFIG. 2 includes a user computing device 204, an access network 206configured to provide access to a CDN for the computing device, and oneor more DNS servers, discussed above. Other components of the network200 of FIG. 2 may also be included in the network 100 environment ofFIG. 1, if not explicitly shown in FIG. 1. The operation of the network200 and components of the network of FIG. 2 are discussed below.

As mentioned above, a user of a CDN 102 may request content or a contentfile from the CDN. In one example, a user of the computing device 204enters a link name (e.g., URL or other identifier) into a browserexecuted on the computing device. The link name is associated with anetwork address within the CDN at which the content may be obtained andprovided to the computing device. For example, the user or the devicemay enter a URL such as http://www.example.com/content into the browserof the computing device 204. Upon entering the URL, the hostname may beextracted by the browser (www.example.com in this particular case),which then sends a request (possibly via a browser program executed onthe computing device 204) to a DNS resolver 202 associated with theuser's access network. The DNS resolver 202 associated with the user'saccess network is sometimes known as the ISP resolver. In one example,the access network ISP resolver 202 has cached an IP address for theprovided URL at which the content available through that URL may beobtained. In other words, the ISP resolver 202 may return an IP addressto the computing device 204 to which the computing device may follow toaccess the content of the URL.

However, while the ISP resolver 202 may be implemented to cacheresponses, the resolver often may not have a cached IP address for theprovided domain name. The ISP resolver 202 may also maintain distinctcaches for subsets of computing devices that use the resolver, and thesubset used by computing device 204 may not have a cached IP addressassociated with the provided domain name, even though the resolver doeshave cached IP addresses for other subsets of computing devices. In suchcases, the DNS resolver 202 transmits a second DNS request to a DNSarchitecture 208 of the CDN to receive an IP address at which thecontent file may be obtained. In some instances, the DNS request fromthe ISP resolver 202 may be transmitted to the DNS architecture 208 todetermine the proper authoritative resolver or server within thearchitecture from which to obtain the IP address. In general, the DNSarchitecture 208 provides a root node hierarchy of DNS resolvers thatrespond to DNS requests by either responding with the IP addressassociated with the provided domain name or directing the requestingdevice 202 through the architecture to the corresponding or proper DNSresolver within the architecture. Through the DNS architecture 208, theDNS request from the ISP resolver 202 is fulfilled (i.e., the IP addressassociated with the request is provided to the ISP resolver). In turn,the ISP resolver 202 may cache the returned IP address for futurerequests received at the resolver and may provide the IP address to thecomputing device 204 in response to the DNS request.

More particularly, when the ISP resolver 202 does not have a cached IPaddress for the requested content within the CDN or does not know whichDNS server may provide the IP address, the ISP resolver transmits a DNSrequest to the root node 210 or root server of the DNS architecture 208.The root node 210 may, in some instances, analyze the request anddetermine a type of URL included in the request. For example, the rootnode 210 may determine if the URL includes a “.com”, “.net”, “.org”,etc. as a part of the entered URL. The DNS architecture 208 may includea DNS resolver 212 for each of the different types of URLs, such as aDNS resolver 213 for .org URL requests, a DNS resolver 215 for .net URLrequests, a DNS resolver 214 for .com URL requests, and so on. Ingeneral, however, the DNS architecture 208 may be arranged in any mannerwith each DNS resolver handling any type of groups of DNS requests fromrequesting devices. Upon determining the type of URL requested, the rootnode 210 may return to the ISP resolver 202 a redirect to acorresponding DNS resolver within the architecture 208.

In one particular example, the ISP resolver 202 may receive a requestfrom the device 204 that includes the URL www.example.com. If the ISPresolver 202 does not have an associated IP addressed cached, theresolver may transmit a second DNS request to the root node 210 of theDNS architecture 208 of the CDN. The root node 210 may analyze therequest and determine the request includes a .com-type URL. The rootnode 210 may then return an IP address for another DNS server in thearchitecture 208 (in this case, DNS 214 for information concerning .comURLs) to the ISP resolver 202. The ISP resolver 202 may then transmitanother DNS request to the .com server 214 and, in turn, may receive anIP address for yet another DNS in the architecture 214 in a similarmanner as the root server 210. For example, the .com server 214 mayanalyze the request and determine that requests that include example.commay be fulfilled by a particular DNS 216 or by multiple DNS 218-222 inthe architecture 208.

The ISP resolver 202 may continue sending DNS requests to the DNSarchitecture 208 until the DNS 216 corresponding to the received URL islocated. In this manner, the ISP resolver 202 is directed to the DNS 216within the architecture 208 for the particular URL and, once the IPaddress corresponding to the URL is obtained, the ISP resolver 202 maycache and/or provide the IP address to the computing device 204. Withthis information, the computing device 204 accesses a device within theCDN at the provided IP address and receives the requested content fromthe CDN.

As mentioned above, the DNS architecture 208 may include one or manyservers that may resolve a DNS request for a particular request. Forexample, any of servers A-D 216-222 may resolve a request for URLexample.com. In some instances, DNS 214 may return an IP address foreach of Server A-D 216-222 to the ISP resolver 202 in response to a DNSrequest. The ISP resolver 202 may then determine which of the availableDNS A-D 216-222 to transmit another DNS request to resolve the URL. Insome networks, the DNS architecture 218 may be spread out throughout anetwork 102 to minimize transmission times for responding to DNSrequests to a server. Thus, ISP resolver 202 may select the server fromthe pool of DNS A-D 216-222 that is geographically closest to the ISPresolver to transmit the next DNS request to obtain the related IPaddress. Regardless of which technique the ISP resolver 202 executes toselect a particular DNS from the pool of DNS 216-222, the DNSarchitecture 208 may provide a plurality of addresses of DNS at whichthe DNS request may be resolved.

As CDNs continue to grow in size, the supporting DNS architecture 208for the CDN may also grow in size such that more and more DNS may beincluded in the DNS architecture 208 to provide capacity and fast returntimes for DNS request. However, returning several addresses of DNS inresponse to a DNS request may not be scalable to match the growth of theCDN. As a result, new approaches for DNS network traffic management andDNS request handling have been developed, including utilizing loadbalancing and anycast techniques in an effort to reduce the size ofresults provided by the DNS system.

In anycast routing, many different devices on the Internet or othernetwork may announce the same Internet Protocol (IP) address (e.g.,1.2.3.4) to which packets may be addressed for transmission. In otherwords, multiple devices within a network 102 may advertise the sameanycast address such that packets with the anycast address (as thedestination address) may be transmitted to any of the multiple devices.The decision on which of the multiple devices to which the packet issent is left to other routing devices of the network 102, such as bydetermining which of the multiple devices is geographically closest tothe transmitting device and routing the packet to that device. Inregards to the DNS architecture 208 discussed above, DNS 214 may returnan anycast address to the ISP resolver 202 in response to a DNS requestindicating that the requested IP address may be obtained from any deviceassociated with the anycast address. Server A-D 216-222 may eachadvertise the anycast address such that the ISP resolver 202 may thenselect one of server A-D to transmit the next DNS request. In thismanner, the number of returned addresses for a DNS request may bereduced through the use of anycast addresses for multiple DNS of thearchitecture 208.

Although utilizing anycast techniques in a DNS architecture 208 mayreduce the number of addresses returned in response to a DNS request,certain limitations to the effectiveness of typical anycast techniquesmay exist. For example, the use of a single anycast address for multipleservers may prevent efficient routing and load balancing of requestssuch that some servers may become overloaded with requests while othersin the network remain idle. Such a limitation is illustrated in thenetwork configuration 300 of FIG. 3A utilizing an anycast address formultiple DNS servers. The network environment 300 of FIG. 3A is anexample deployment of one implementation of a portion of a DNSarchitecture 208 of the proposed system within a gateway to provide DNSresolution in a CDN 106.

In some network configurations, several domain name servers may beconnected to a router. In the particular example of FIG. 3A, networkenvironment 300 includes a plurality of domain name servers (ServerA-Server F 304-314) in communication with router A 302. Router A 302receives DNS requests from network 102 and provides the request to oneof DNS servers 304-314 based on a network address or identifierannounced by the servers 304-414. More particularly, the DNSarchitecture 208 of FIG. 2 may provide an anycast address to the ISPresolver 202 in response to a request to resolve a domain name. Each ofthe servers 304-314 of the network environment 300 of FIG. 3A may beassociated with the anycast address provided to the ISP resolver 202.The resolver 202 may then transmit another DNS request to the network102 with the anycast address as the destination address. As each of theservers 304-314 announce the same anycast address to receivecommunications, the network 102 may route the DNS request to router A302 for forwarding on to one of the anycast DNS servers 304-314. Thetechniques by which the router 302 determines which of servers A-F304-314 receive the DNS request is discussed in more detail below. Uponreceipt of the DNS request, the receiving server may resolve the domainname to an IP address associated with the requested content and returnthe IP address to the ISP resolver 202 for further processing.

The network 102 (or more particularly, the components of the network)may receive addresses announced by the servers A-F 304-314 through oneor more external border gateway protocol (EBGP) sessions between theservers and the router 302 and between the router 302 and the network102. Through the EBGP session, each server 304-314 announces an addressof the server for receiving communications from the network 102. Theannouncements are made with an associated router (such as nearest routerA 302). The router 302 announces all received addresses to one or morecomponents of network 102 such that the devices of the network mayidentify servers A-F 304-314 as destinations for communication thatinclude a destination address associated with one or more of theservers. Although discussed within as utilizing EBGP techniques foraddress announcements, other techniques to announce routes betweencomponents of the systems disclosure herein may be used inimplementations of the present disclosure. For example, in certainapplications, a control system that injects BGP routes into an edgerouter or route reflector may also be used to announce routes andaddresses of the networking devices.

In a typical anycast configuration, more than one device may announcethe same address as capable of responding to a communication of thenetwork 102. Thus, each of server A 304 through server F 314 mayannounce the same anycast address (referred to in FIG. 3A as anycastaddress 1). Router A 302 similarly announces the received anycastaddress 1 to network 102 as being connected to a device that may respondto a communication associated with the anycast address. The router A302, upon receiving a communication with the anycast address as thedestination address, may select from the available servers A-F 304-314to transmit the communication. In one implementation, router A 302 maysupport Multipath Load Sharing. That is, if there are multiple EBGPsessions at the router 302 through which the router receives a route tothe same anycast address, the router attempts to balance receivedtraffic between each of the devices providing the same anycast addressso as not to overload one of the destination servers 304-314. However,many load balancing routers 302 may only support a limited number ofroutes per anycast address or prefix. Thus, a given prefix/DNS IPaddress might only be able to have a limited number of load-balanceddestinations. For purposes of example, router A 302 may be limited insupporting four destinations for a given address. As shown in table 320of FIG. 3A, assume server A 304 through server F 314 each advertiseanycast address 1 to router A 302 such that router A may select fromeach of servers A-F for a received communication associated with anycastaddress 1. However, router A 302 may be limited to four destinations forload balancing for a given address such that only server A 304, server B306, server C 308, and server D 310 may receive communications fromrouter A 302 for the anycast address. Server E 312 and server F 314,although available to receive DNS requests, may not be used as router A302 limits the load balancing between server A 304 through server D 310.As such, the full capacity of the DNS architecture 208 or networkconfiguration is not utilized.

To resolve the issue of under-utilization of the network 300, multipleanycast address may be announced by the servers of the networkenvironment. In particular, FIG. 3B is an example network environmentfor utilizing a plurality of anycast addresses for multiple DNS servers.The components of network environment 350 are the same or similar tothat of FIG. 3A, including router A 302 connecting server A 304 throughserver F 314 to network 102. However, in this example, servers A-F304-314 may announce multiple anycast addresses. In particular, fouranycast addresses may be used and spread among the servers 304-314behind router A 302. Although discussed as advertising four anycastaddresses, it should be appreciated that any number of anycast addressesmay be used by the environment 350 for any number of DNS serversserviced by a router 302. In the example shown, the four anycastaddresses are announced by the servers 304-314 such that no address isannounced by more than four servers (the limit for load balancing ofrouter A 302). Thus, server A 304, server B 306, and server C 308 mayannounce both anycast address 1 and anycast address 3. These servers304-308 may receive DNS requests with a destination address of anycastaddress 1 or anycast address 3. Similarly, server D 310, server E 312,and server F 314 may announce both anycast address 2 and anycast address4 such that the servers 310-314 may receive DNS requests with adestination address of anycast address 2 or anycast address 4. Further,because the number of devices associated with any one of the anycastaddresses does not exceed the limit for load balancing at the router A302, each server 304-314 of the cluster of servers is utilized by therouter. For example, requests destined for anycast address 1 may beequally distributed and handled by each of server A 304, server B 306,and server C 308, while requests destined for anycast address 2 may beequally distributed and handled by each of server D 310, server E 312,and server F 314. The use of multiple anycast addresses announced by aserver of the cluster 304-314 may therefore result the utilization ofall available servers behind router A 302, as shown in table 352 of FIG.3B. Additional advantages for the use of multiple anycast addresseswithin a cluster are discussed in more detail below.

To determine which anycast addresses are advertised, each DNS server304-314 may perform a repeatable and consistent hash-function thatdetermines the advertised anycast addresses. For example, thehash-function may determine to one or more of the anycast addressesutilized by the DNS architecture 208 to begin advertising. In someinstances, the hash-function may include as an input a number of serversin a cluster. For example, server A 304 may determine that six serversin total are connected to router A 302 and that four anycast addressesare available to advertise. Through the hash function, server A 304 maydetermine to advertise anycast addresses 1 and 3. The other servers B-F306-314 may also execute the same hashing function to determine whichanycast addresses to announce to generate the spread addressdistribution among the cluster of servers 304-314. Through the hashingfunction, the servers 304-314 may operate independently to determine theadvertised addresses, although a centralized controller may be used toinstruct one or more of the servers to announce particular anycastaddresses.

In some network configurations, multiple routers or other networkingdevices may be located within a geographical area, sometimes referred toas a “metro”. For example, a telecommunications network may locateseveral routers in a large city area, such as New York City. FIG. 4A isan example network environment 400 for utilizing an anycast address formultiple DNS servers 410-420 within the same metro area 422. Thecomponents of the network environment 400 may operate similar to thatdescribed above, such that multiple servers (e.g., server A 410 throughserver F 420) may receive and respond to DNS requests. Router A 406 androuter B 408 may receive such DNS requests from one or more networks(illustrated as peer network A 402 and peer network B 404), identify theserver indicated in the received request, and forward the request to theidentified server. Router A 406 and router B 408 may also be incommunication such that received communications may be transmittedbetween the routers.

In the particular environment 400 of FIG. 4B, server A 410, server B412, and server C 414 are in communication with router A 406 andannounce the anycast address 1 to router A. Router A 406 is incommunication with a peer network A 402 to receive DNS requests frompeer network A. As described above, router A 406 may load balancereceived DNS requests between server A 410 through server C 414 as eachof the servers announces the same anycast address. Server D 416, serverE 418, and server F 420 are in communication with router B 408 and alsoannounce the anycast address 1 to router B. Router B 408 is incommunication with a peer network B 404 to receive DNS requests frompeer network B. Router B 408 may also load balance received DNS requestsbetween server D 416 through server F 420 as each of the serversannounces the same anycast address.

As shown in the table 424 of FIG. 4A, server A 410, server B 412, andserver C 414 may be used by router A 406 for processing received DNSrequests, while server D 416, server E 418, and server F 420 may be usedby router B 408. If peer network A 402 provides a similar load of DNSrequests as peer network B 404, then each server may process similarloads among all six DNS servers 410-420 as router A 406 and router B 408may be configured to distribute DNS requests across available DNSservers. Further, although router A 406 may transmit received requeststo router B 408 for transmission onto any of server D 416 through serverF 420, each router may typically use the routes seen from the serversdirectly connected to the router due to a BGP path selection rules thatprioritizes EBGP routes (e.g., routes received from the connected DNSservers) over internal BGP (IBGP) routes (e.g., routes received fromother routers.

Although each server 410-420 of the metro 422 may be utilized by thenetwork environment 400 to satisfy DNS requests, some issue may arise.For example, assume that all six servers 410-4120 represented receive anequal amount of traffic, but server A 410 goes offline or suffers someother reduction in performance level. In such a circumstance, server B412 and server C 414 may begin receiving the traffic that was going toserver A 410. As a result, server B 412 and server C 414 will experiencean increase in traffic load, while server D 416 through server F 420continue at the current load as none of the load previously beinghandled by server A 410 will be distributed to server B 412 and server C414. This may reduce the effectiveness of server B 412 and server C 414as the load within the metro 422 is not evenly distributed across allavailable servers. Another issue may arise from the traffic receivedfrom peer network A 402 and peer network B 404 being unbalanced. Forexample, peer network A 402 may be a larger CDN customer to the network102 and provide significantly more requests to the metro 422 than peernetwork B 404. In such circumstances, all of the traffic transmitted torouter A 406, which corresponds to the majority of traffic for the metro422, may be transmitted to server A 410, server B 412, or server C 414,while servers D-F 416-420 handle a relatively small quantity of traffic.This unbalanced processing of received requests at the metro 422 networkmay not maximize the efficiency of the server capacity for the metro.

Employing multiple anycast addresses for the servers 410-420 of themetro 422 may aid in balancing the request traffic across all availableservers. For example, FIG. 4B is an example network environment 400 forutilizing a plurality of anycast addresses for multiple DNS servers410-420 within the same metro 422. The components of network environment450 are the same or similar to that of FIG. 4A, including router A 406connected to servers A-C 410-414 and router B 408 connected to serversD-F 416-420, with router A 406 in communication with peer network A 402and router B 408 in communication with peer network B 404. However, inthis example, servers A-F 410-420 may announce multiple anycastaddresses. In particular, four anycast addresses may be used andannounced by the servers 410-420 in a similar announcing scheme asdiscussed above. The multiple anycast addresses may aid in loadbalancing DNS requests across the DNS servers 410-420 of the metro 422.

In particular, as shown in table 426, server A 410, server B 412, andserver C 414 may announce anycast addresses 1 and 3, while server D 416,server E 418, and server F 420 may announce anycast addresses 2 and 4.Similar to above, each router 406, 408 may load balance requests tothose servers respectively connected to the routers. Further, becauserouter A 406 is connected to router B 408, requests received at eitherrouter may be spread across all of the available servers 410-420. Inparticular, router A 406 may receive a DNS request from peer network A402 with a destination address of anycast address 2. Because none ofserver A-C 410-414 announce anycast address 2, router A 406 may transmitthe request to router B 408 (as router B may have received anycastaddress 2 from servers D-F 416-420 and announced anycast address 2 torouter A). In this manner, router A 406 may utilize the servers D-F416-420 behind router B 408 for DNS requests associated with anycastaddress 2 or anycast address 4. Similarly, router B 408 may utilize theservers A-C 410-414 behind router A 406 for DNS requests associated withanycast address 1 or anycast address 3. Thus, each of router A 406 androuter B 408 may utilize each of the servers 410-420 of the metro 422 toresolve received DNS requests, whether received from peer network A 402at router A or peer network B 404 at router B. The DNS requests may thusbe load balanced across all of the available servers 410-420, regardlessof which peer network 402-404 or through which router 406-408 therequest is received.

Other network environments may utilize multi-anycast addressing schemesor techniques to improve DNS request handling within a metro. Forexample, FIG. 4C is an example network environment 452 for utilizing aplurality of anycast addresses for multiple DNS servers 458-468 withinthe same metro 470 by splicing the plurality of anycast addresses acrossthe multiple DNS servers. In this configuration, router A 454 may beconnected to peer network A 402 and router B 456 may be connected topeer network B 404 as above. However, DNS servers A-E 458-466 may beconnected to router A 454 while DNS server F 468 may be connected torouter B 456. Thus, router A 454 may serve requests to five servers,while router B 456 transmits request to one server. Each of the DNSservers A-E 458-466 may be configured to announce multiple anycastaddresses for receiving DNS requests. In the network environment 452illustrated, however, the announcement of the anycast addresses may bespliced among the available servers in a round-robin fashion. Forexample, assume a DNS architecture that utilizes 16 different anycastaddresses for use in reaching DNS servers of the architecture. In theparticular configuration of FIG. 4C, server A 458 may announce anycastaddresses 1, 7, and 13, server B 460 may announce anycast addresses 2,8, and 14, server C 462 may announce anycast addresses 3, 9, and 15,server D 464 may announce anycast addresses 4, 10, and 16, server E 466may announce anycast addresses 5 and 11, and server F 468 may announceanycast addresses 6 and 12. By slicing the multiple anycast addressesacross the servers A-F 458-468, traffic load may be spread across theservers, regardless of which peer network 402, 404 from which thetraffic is received and which router 454, 456 receives the traffic. Inparticular, server A 458 may process DNS requests associated with theanycast address 1, server B 460 may process DNS requests associated withthe anycast address 2, server C 462 may process DNS requests associatedwith the anycast address 3, and so on. By slicing the anycast addressesthat are announced by the servers A-F 458-468, the load of DNS requestresponses may be spread across all of the available servers of the metro470.

In a similar manner, DNS request traffic loads may be spread acrossmultiple metros of a telecommunications network. Different metros of atelecommunications network may experience different loads and may not beable to redistribute traffic to prevent overloading of devices, such asrouters or servers, of the metro. Such uneven loading may beparticularly problematic during a distributed denial of service (DDoS)or similar attack, when an operator could benefit from using allavailable capacity of a network to handle the sharp increase in trafficresulting from the attack. FIG. 5A illustrates an example networkenvironment 500 for utilizing a plurality of anycast addresses formultiple DNS servers 510-524 within multiple metros 526-530 or gateways.In particular, the network environment 500 includes a first metro 562 orgateway (located in New York City in this example). The NYC metro 562includes a first router (router A 502) connected logically betweenmultiple DNS servers A-C 510-514 and a network 102. A second router(router B 504) may also be connected between multiple other DNS serversD-F 516-520 and the network 102. Further, sixteen anycast addressesutilized by a DNS architecture 208 to which the DNS servers 510-520belong may also be spliced across the six servers of the NYC metro 526,as described above. The network environment 500 also includes a secondmetro 528, located in Cleveland in this example. The Cleveland metro 528includes a router (router C 506) connected to DNS server G 522. Server G522 may announce anycast addresses 1-16 such that all DNS requestsreceived at router C 506 are transmitted to server G 522 for resolution.A third metro 530, located in Washington D.C. in this example, similarlyincludes a DNS server (server H 524) connected to router D 508. Eachrouter A-D 502-508 is connected to the other routers of the environment500. Although shown as being directly connected, it should beappreciated that routers A-D 502-508 may connect over network 102 fortransmissions of communications between the routers. Server H 524 maysimilarly announce anycast addresses 1-16 such that all DNS requestsreceived at router D 508 may be resolved by server H 524.

In the example environment 500, DNS requests are load balanced acrossthe servers within a particular metro 526-530. For example, because onlyone DNS server 522 is located in the Cleveland metro 528, all requestsreceived in the Cleveland metro may be transmitted to server G 522 forresolution and response. On the other hand, the NYC metro 526 includessix servers 510-520 that can handle DNS requests. The anycast addressesutilized by the DNS architecture 208 may be spread out among the servers510-520 of the NYC metro to load balance the requests among theavailable servers in that metro.

In some instances, one or more of the servers 510-524 of the networkenvironment 500 may become overloaded with requests. This may occur formany reasons, such as due to a denial of service attack or an unusualdemand for domain name resolution. When a potential overload conditionis detected at one or more of the DNS servers 510-524 of the environment500, the overloaded server or servers may cease announcing one or moreof the previously announced anycast addresses to redirect those requeststo other servers/routers of the environment 500. For example, assumeserver G 522 (or a central monitoring device) detects a potentialtraffic overload condition at server G. The overload condition may bedetected in many ways, including but not limited to, a rate of receivedtraffic meeting or exceeding a threshold, a forecast of future receivedtraffic based on current trends of received traffic, detected attacks onone or more components of the network 500, information or data receivedfrom the network 102 or an administrator of the network, and the like.Regardless of how an overload condition of a server is determined, theserver 522 that is overloaded or may become overloaded may ceaseannouncing one or more of the anycast addresses to redirect requestsassociated with those addresses to other servers in the environment 500.For example, server G 522 may cease announcing anycast addresses 9-16,as shown in the network configuration of FIG. 5B. In other words, serverG 522 may only announce anycast addresses 1-8 in response to thedetected overload condition, when previously the server announcedanycast addresses 1-16. The stopping of announcements for anycastaddress 9-16 may be detected by router C 506 (such as through standardBGP announcement procedures) such that router C 506 may, when DNSrequests are received at router C 506 from network 102 associated withany of anycast address 9-16, router C 506 may transmit the requests toanother router within the environment 500. For example, router C 506 maytransmit requests associated with anycast addresses 9-16 to the NYCmetro 526 for processing. Requests associated with anycast addresses 9,13, 14, and 15 may be transmitted to router A 502 (based on announcedanycast address 13 from server A 510, announced anycast address 14 fromserver B 512, or anycast address 9 and 15 from server C 514). Requestsassociated with anycast addresses 10-12 and 16 may be transmitted torouter B 5045 (based on announced anycast address 10 and 16 from serverD 516, announced anycast address 11 from server E 518, or anycastaddress 12 from server F 520). In this manner, server G 522 may attemptto redirect traffic, and thereby lessen the traffic load condition atserver G, to other routers 502, 504 in the network environment 500 inresponse to a detected overload condition.

Other servers may also redirect traffic to other routers in response toa detected overload condition. For example, server A 510 may, upondetection of an overload condition, may cease advertising anycastaddress 13 to reduce the flow of request traffic to the server. Otherservers of the environment 500 may then respond to DNS requestsassociated with anycast address 13, such as server G 522 of Clevelandmetro 528 or server H 524 of a Washington D.C. metro 530. Further still,other servers 512-520 within the NYC metro 526 may begin announcinganycast address 13 to begin receiving such DNS requests to take the loadfrom server A 510. For example, server E 518 may begin announcinganycast address 13 to begin receiving those DNS requests. If theoverload condition persists, server A 510 may also cease announcinganother anycast address, such as anycast address 7. By ceasingannouncements of particular anycast address, overloaded servers maybegin to shed traffic to other servers of the DNS architecture until theoverload condition ends.

To determine which anycast addresses the server 522 may ceaseadvertising, DNS servers 510-524 may perform a repeatable and consistenthash-function that determines which of the advertised anycast addressesto stop advertising. For example, the hash-function may determine tostop advertising the highest anycast address being broadcast when theoverload condition is determined. Another hash-function may include asan input which anycast addresses are announced within the same metro asthe overloaded server such that the anycast address that is shed by theoverloaded server is at least partially based on whether other serversin the metro also advertise the anycast address. In some instances, itmay be desirable to shed traffic to other metros, even when the metromay be geographically further away from the requesting device. Therequesting device (such as ISP resolver 202) generally selects the DNSserver that is geographically nearest the requesting device. Thus, ifserver G 522 of the Cleveland metro 528 sheds anycast addresses byceasing to advertise addresses (such as anycast addresses 9-16), therequesting device may determine that the servers 510-520 in the New Yorkmetro 526 and route the DNS request to the nearest router in that metro.In this manner, the DNS servers 510-524 of the network environment 500may respond to overloaded conditions by shedding traffic to otherservers in other metros 526-530 within the environment. Further, unliketypical load balancing done with DNS servers, load balancing here isperformed via BGP so delays are minimized (as BGP typically operateswithin seconds) and each server may operate independently.

Although servers 510-524 within the environment 500 may shed or ceaseadvertising anycast addresses, the network 500 may not want idle routersor servers that do not announce any anycast address. For example, whileserver G 522 may shed DNS requests to the NYC metro 526 (or othermetros) in response to an overload condition, ceasing to announce allanycast addresses from server G 522 may result in the server becomingidle or receiving no DNS requests. Similarly, router C 506 may alsobecome idle based on server G 522 ceasing announcement of anycastaddresses. To prevent idle components of the network 500, each servermay be associated or programmed with a default or preferred anycastaddress from the range of available anycast addresses. The preferredanycast address may be based on the router to which a given server isconnected such that more than one server may be associated with thepreferred anycast address. In general, each server associated with agiven router always advertises the preferred anycast address for thatrouter so that at least one address is advertised for each router of thenetwork 500. By always advertising at least a preferred anycast address,the routers 502-508 of the network 500 may continue to receive DNSrequests.

FIG. 5C is the example network environment 500 of FIG. 5A in response toone or more overload conditions at one or more of the multiple DNSservers by announcing one or more preferred anycast addresses. In thisexample of the network 500, server G 522 of the Cleveland metro 528 maydetect an overload condition and cease announcing one or more anycastaddresses to reduce the DNS request traffic transmitted to server G 522via router C 506. As the overload condition increases or continues,server G 522 may shed more and more anycast addresses until a singleanycast address is advertised by the server. Router C 506 of theCleveland metro 528 may also be associated with a preferred anycastaddress such that servers connected to router C 506 may announce thepreferred anycast address, regardless of a detected overload conditionat the server. In the example shown in FIG. 5C, the preferred anycastaddress for router C 506 may be anycast address 1. Thus, server G 522may continue to announce anycast address 1 despite a detected overloadcondition at the server. In general, any of the available anycastaddress for the DNS architecture 208 may be associated with a particularrouter of the network 500 as the preferred address for that router. Thepreferred anycast address for a particular router may be determined orprovided by a central controller or an administrator of the network 102upon configuration of the network environment 500. The serversassociated with the particular router may be configured as discussedbelow to store and announce the preferred address for that router.

Continuing the above example, overload conditions may also be detectedat server A 510, server B 512, and server C 514 at the NYC metro 526. Inresponse, servers A-C 510-514 may also shed addresses to other serversin the network 500. In one example, servers D-F 516-520 in the NYC metro526 may begin announcing the shed anycast addresses from servers A-C510-514. In another example, the DNS request traffic may be redirectedto server H 524 of the Washington D.C. metro 320 based on the anycastaddresses announced by server H 524. Regardless of to which servers therequests are redirected, servers A-C 510-514 may continue to shedaddresses for the duration of the overload condition. However, serversA-C 510-514 may not cease announcing the preferred anycast addressassociated with router A 502 to which the servers are connected. In theexample of FIG. 5C, router A 502 has an associated preferred anycastaddress of address 2 such that servers A-C 510-514 continue to announcethe preferred address despite the overloaded condition at those servers.In a similar manner, router B 504 may also be associated with apreferred address (such as anycast address 3) and router D 508 may beassociated with a preferred address (such as anycast address 4). Theservers connected to or otherwise associated with those routers 504, 508may announce the preferred address. Notably, it is possible to reusepreferred addresses in certain situations such as when they are used forlocations far apart (e.g., different continents).

Another issue that may arise when utilizing anycast addressing in a DNSarchitecture 208 is the potential for a router or other networkingcomponent “black-holing” some requests. Black-holing of requests occurswhen a router or other component advertise one or more addresses forresolution by a server behind the router, but no server may be availableto respond to the request, due to a malfunctioning server or otherfailure of the devices, such that the request goes unanswered. Tomitigate this circumstance, some anycast addresses may be excluded fromone or more metros or routers. For example, FIG. 5D is the examplenetwork environment 500 of FIG. 5A limiting one or more anycastaddresses for the multiple metros 526-530. In the example shown, therouters/servers of the NYC metro 526 may not announce one or moreanycast addresses, such as anycast address 15 and anycast address 16.Rather, those addresses may be announced from other metros, such asCleveland metro 528 and/or Washington D.C. metro 530. Thus, if it isdetermined that DNS requests associated with address 15 and address 16are not being responded to from the NYC metro 526, such addresses may beremoved from announcements from router A 502 and router B 504 (or therelated servers 510-520 of the metro 526). Similarly, anycast address 2and anycast address 3 may be excluded from Cleveland metro 528 such thatthose requests may be answered by the NYC metro 526 and/or theWashington D.C. metro 530. The alternate metros 526-530 to respond toparticular DNS requests may be, but are not necessarily, geographicallyclose to the excluded metro such that the response for DNS requests maystill be relatively fast. Through the exclusion of one or more anycastaddresses from one or more metros 526-530 of the environment 500, deador black-hole devices of the network 500 may be avoided. The exclusionof one or more anycast addresses from a metro 526-530 may also beutilized during load balancing within a metro. For example,non-preferred addressed may be pooled in metros which have similardelays. As servers begin shedding addresses due to overloading, theother servers in the same metro 526 may also cease advertising the shedaddress of the server as the servers within a metro may be treated as a“pool” of servers. For example, server A 510 and server B 512 may bothadvertise anycast address 10 in NYC metro 526. If server A 510 shedsanycast address 10 due to overloading, server B 512 may also beconfigured to shed anycast address 10 such that no server in NYC metro526 advertises that address. Rather, DNS requests associated withanycast address 10 may then be transmitted to Cleveland metro 528 orWashington D.C. metro 530, assuming those metros continue to advertisethe anycast address 10. As mentioned above, however, servers may refrainfrom advertising a preferred anycast address for the router to which theserver is connected.

In some circumstances, a BGP session may stop working properly, such asif a router filters out all advertised addresses received from a DNSserver but keeps the session up. When this occurs, a connected DNSserver may have no way of knowing internally that such a situation hasoccurred and the addresses are not being announced. Other examples ofproblematic situations that may arise are when the router isn'taccepting any routes or when the router is accepting routes, butsomething is wrong within a metro such that traffic that should staylocal is instead exported to another metro.

The network environment may implement mechanisms and techniques foraddressing such circumstances. In one implementation, a uniquemonitoring address may be assigned to each server within the network tomonitor the functionality of the server. FIG. 6 is the example networkenvironment 500 of FIG. 5A, with each of the multiple DNS servers510-524 advertising a unique anycast address to monitor the serverperformance of each server. In particular, server A 510 may advertise IPaddress A, server B 512 may advertise IP address B, server C 514 mayadvertise IP address C, and so on for each server in the DNS network500. IP address A, IP address B, IP address C, etc. may be unique IPaddresses, different than the anycast addresses utilized by the DNSnetwork 500. Each unique address is announced via BGP such that theunique IP address may be used to monitor the respective server from theentire network 102 to ensure that the BGP session is functioningproperly. In particular, if a unique IP address cannot be reached by thenetwork 102, an error may be raised to examine the respective server tocheck for failures at the server. In this manner, monitoring for theunique IP address announced by each server 510-524 of the network 500may provide an indication of the operability of the servers.

Another mechanism that may be implemented in the network 500 ismonitoring of DNS pool addresses within a metro. For example, where morethan one DNS server is in a metro (such as server A-F 510-520 of NYCmetro 526), all DNS pool unique IP addresses assigned to servers withinthe same metro may be monitored from the other DNS servers in that metro526 to ensure they are answered within the metro. In one example, thismay be accomplished using a DNS lookup technique using the anycastaddress that returns the hostname/“a-name” of the responding server. Ifthe responding server is not a machine in the same metro or the addressis completely unreachable, an error may be raised. Such a mechanism maybe implemented in conjunction with or independently of the dedicatedmonitoring IP addresses discussed above.

The network configurations discussed above may be implemented in severalways to provide the multiple anycast address announcements of the DNSservers of the DNS architecture 208. For example, the components of thenetwork, including the routers and DNS servers, may be implemented tosupport both IPv4 and IPv6 protocols. Further, in some implementations,specific data may be provided to each DNS server within the network 208to facilitate the previously discussed functionality. For example, acentral computing system may be used to manage configuration data of thecomponents of the network 208, which may then be pushed out to each ofthe DNS servers within the architecture. Examples of configuration datathat may be provided to each of the DNS servers may include, withoutlimitation, host flags for each of a group name of a group to which thereceiving DNS server belongs, BGP peer IP addresses (e.g., IPv4 andIPv6), a BGP self-autonomous system number (ASN), a BGP peer ASN, anIPv4 monitoring IP address, and an IPv6 monitoring address.Configuration information may also be maintained for each group of DNSservers (e.g., each set of DNS servers coupled to a given router). Suchgroup configuration information may include a preferred IPv4 and/or IPv6address for the group. As previously discussed, such a preferred addressmay generally correspond to an anycast address that each DNS serverwithin the group advertises. Global configuration data that may bestored and maintained may include a list of IP addresses to include in agiven pool. In certain implementations, such a list may allow at least64 anycast addresses for each IPv4 and IPv6 and should generally allownon-contiguous addresses. Additional configuration data may bemaintained on a per-metro basis. For example, such information mayinclude a list of anycast addresses to be excluded from a given metro

In some implementations, when establishing a new group or an initial setof DNS servers on a given router, a unique “preferred pool anycastaddress” may be assigned to the group. Such a preferred pool address maybe provided for each protocol supported (e.g., each of IPv4 and IPv6).In general, the preferred pool anycast address may be any pool addressnot used by another group as a pool anycast address. Further, aspreviously noted, certain anycast addresses may be excluded from a givenmetro. Accordingly, configuration of the system may include identifyingthe particular anycast addresses to be excluded from each metro withinthe system. In systems supporting multiple protocols, addresses may beexcluded for each protocol. So, for example, in systems supporting bothIPv4 and IPv6, excluding a given exclusion may include exclusion of eachan IPv4 address and an IPv6 address. In certain implementations, theanycast addresses excluded from one metro may not be the same as thoseexcluded from any other metro's excluded addresses.

As previously noted, each DNS server added to the network 500 may beassigned a unique monitoring address. In systems supporting multipleprotocols, a monitoring address may be provided for each of protocols(e.g., an IPv4 monitoring address and an IPv6 monitoring address). Suchaddresses may be specifically chosen to be outside the range ofaddresses eligible to be announced to the next hop router such that theyare specifically reserved for monitoring purposes.

FIG. 7 is a flowchart of a method 700 for utilizing a plurality ofanycast addresses in a DNS architecture of a CDN. The method 700 may beperformed by one or more DNS server of a DNS architecture 208 of anetwork, such as a CDN. The operations of the method 700 may beperformed through execution of a software program, a hardware orcombination of hardware components, or a combination of both hardwareand software components of the DNS server. In other implementations, themethod 700 may be performed by other components of a telecommunicationsnetwork or a content delivery network. Further, one or more of theoperations may be performed by other separate components of the network,including some performed by a DNS server and others performed by acentral controller of the DNS architecture 208.

Beginning in operation 702, the server may announce a correspondingunique IP address for monitoring purposes, as described above. Forexample and utilizing the network configuration 500 of FIG. 6, server A510 may announce unique IP address A such that other components of thenetwork 102 and the metro 526 to which the server is connected maymonitor for the announcement of unique IP address A to determine ifserver A is present in the network 500. In operation 704, the DNS servermay determine if the sever is operational. For example, server A 510 maymonitor the internal operation of the server to determine if one or moreoperational faults is occurring. If the server is not operational, theserver may withdraw all previously announced anycast addresses (througha BGP session with connected device), except for the unique IP addressin operation 706. This operation removes the server from receiving DNSrequests until the operational status of the server can bere-established. The server may return to operation 702 to again announcethe unique IP address for the server and continue to monitor the serverfor an operational status.

If the server is operational, the server may announce the grouppreferred anycast address associated with the router to which the serveris connected in operation 708. For example and as described above, oneor more routers of the network 500 may be associated with a preferredanycast address from the available anycast addresses utilized by thenetwork. The preferred anycast address is routinely announced by theservers connected to the router such that each server may receiverequests associated with at least one anycast address. As previouslydiscussed, such preferred addresses generally correspond to anycastaddresses that will be advertised by DNS servers within a particulargroup (such as a group of servers connected to a particular router orother networking device). In some implementations, each list of suchaddresses may be transmitted or otherwise pushed out to its respectiveDNS server by a centralized configuration computing device. In general,the centralized configuration computing device may provide globalconfiguration information to DNS servers in the DNS architecture 208,including BGP configurations, monitoring IP addresses, group or groupsof servers to which a particular server belongs, and/or the number ofservers within the group.

In operation 710, the server may build a list of pool anycast addressesthat are not excluded for the metro in which the server is located. Forexample, server A 510 of the network environment 500 of FIG. 5D mayreceive an indication of the metro 526 to which the server belongs andthe pool of available anycast addresses for that metro. In the example,the NYC metro 536 excludes anycast addresses 15 and 16, but mayadvertise anycast addresses 1-14. Further, server A 510 may receive anindication of the other five servers 512-520 in the metro 526. The poolof anycast addresses of the metro 526, excluding anycast addresses 15and 16, may be built by server A from this information associated withthe metro. In operation 712, the server may execute a hashing functionor technique to determine which of the available pool of anycastaddresses for that metro 526 to announce. As described above, the poolof available anycast addresses may be sliced between the availableservers of the metro. Using the NYC metro 526 as an example, six serversare available to respond to DNS requests such that the available pool ofanycast addresses for that metro 526 may be sliced among the availableservers 510-520. The hashing function or algorithm executed by eachserver 510-520 of the NYC metro 526 may determine which anycastaddresses each server announces to slice the addresses across theavailable servers in the group or metro. For example and based on thehashing function, server A 510 may determine to announce anycastaddresses 1, 7, and 13. Other servers within the metro 526 announceother anycast addresses, including some that may overlap with otherservers in the group (such as one or more preferred anycast addresses ofa router). The hashing function may be repeatable for all servers suchthat no centralized control over the determination of which anycastaddresses are selected by which servers is needed. However, in someimplementations, such a list may be provided to the DNS server from acentralized configuration system. Such a hashing function may generallyinclude evenly or otherwise distributing the pool of non-excludedanycast addresses across a known number of available DNS servers withina group to identify which of the anycast addresses are to be advertisedby the DNS server executing the hashing algorithm.

In operation 714, the server may apply a shedding technique to thedetermined sliced anycast addresses for that server upon a detection ofan overload condition. As mentioned above, an overload condition mayoccur when traffic to a server meets or exceeds a threshold value, aforecast of future received traffic based on current trends of receivedtraffic meets or exceeds a threshold, detected attacks on one or morecomponents of the network, information or data received from the network102 or an administrator of the network, and the like. The sheddingtechnique may identify one or more anycast address from the slicedanycast addresses for the server to shed or cease announcing. Forexample, server A 510 may execute the shedding algorithm to determineanycast address 13 as an address to shed when overloaded. Additionalanycast addresses may be determined to be shed, based on a type ofoverload condition and/or a duration of the detected overload condition.In operation 716 and after the server determines which anycast addressesfrom the pool of addresses for the metro are sliced to that server andwhich anycast addresses are shed due to an overload condition, theserver may announce the determined anycast addresses for that server.The execution of each of the hashing algorithm and the shed algorithmresults in a list of anycast addresses that are not to be advertised bythe DNS server. Accordingly, the DNS server may withdraw such anycastaddresses from those advertised by the DNS server and thenannounce/advertise any anycast addresses that are not otherwise excludedor withdrawn.

The server may return to operation 702 to begin the announcement loopagain and, as a result, may be periodically executed by the DNS serverto dynamically update the anycast addresses that it advertises. Forexample, in certain implementations the method 700 may be executed everyminute (or some other periodic time period) such that the DNS servermaintains a current list of advertised anycast addresses based onloading conditions within the network. Further, each DNS server in theDNS architecture 208 may know whether other DNS servers within its groupor metro are functional. This information may then be used duringexecution of the hashing algorithm to determine which of thenon-excluded anycast addresses are to be assigned to each DNS server. Incertain implementations, each DNS server within a group or metro maydetermine the status of each other DNS server within the group using themonitoring addresses assigned to each DNS server. Because each addressis preferred somewhere within the network, at least one DNS server willbe advertising each anycast address. As a result, synchronization ofstatus information for each DNS server is not necessarily required insome implementations, although such information may be used whenexecuting the consistent hash algorithm (or similar algorithm) forslicing anycast addresses between devices.

In some implementations, the shedding algorithm of the method 700 may betuned to remove anycast addresses advertised by a DNS server relativelyquickly but to add them back to the DNS server relatively slowly. Forexample, shedding may be triggered if the load experienced by the DNSserver is high for a minute or longer but five or more minutes of lowtraffic may be required before the DNS server begins re-advertising anyshed addresses. In some implementations, the shed algorithm may attemptto estimate capacity. For example, central processing unit (CPU)utilization of the DNS server may be retrieved or determined and used asthe primary factor in deciding whether to shed traffic. So, if CPUutilization is at 90% and a threshold of 80% utilization is applied, 1/9(i.e. 11.1%) of the anycast addresses for the DNS server may be shed.Conversely, the quantity of shed anycast addresses may be reduced ifloading of the DNS server falls after an initial shedding operation. Forexample and using the same 80% utilization threshold, if the load fallsto only 20% and 90% of anycast addresses are have been shed by the DNSserver (i.e., 10% of all IP addresses result in 20% loading), thepercentage of shed addresses may be reduced to 60% of all anycastaddresses.

Further, some implementations may utilize a daemon to announce BGProutes between the DNS servers and routers. Such a daemon may be arelatively simple announcement-only type of daemon that may includealarming capabilities. Some implementations may also delegate domainswithin the DNS architecture 208. For example, the .NET domain and the.ORG domain may be split between the domains to ensure that an issuewith any domain will minimize disruption. Such an approach may alsominimize the packet sizes sent from any global top-level domain (GILD)servers. Authority records for some delegations may then be served fromrespective sets of static DNS servers. For example, using the delegationprovided above, .NET authority records may be served from one set ofstatic DNS servers while .ORG authority records may be served fromanother.

In addition to the above, certain implementations may support customerdomains being delegated to broader network operators. For example, inone implementation, 64 anycast addresses with names such as dns-01,dns-02, dns-03, dns-64 may be provided with each name being assigned aunique IP out of the pool addresses. These names may be associated withwildcard records. So, for example, foo.dns-01 may return a result fordns-01. Each customer that delegates to the network operator may get alist of DNS servers (e.g., a list of 8 DNS servers) to use from thislist, and a unique customer-specific prefix to use such that delegationsmay be changed at a later date. For vanity DNS servers (i.e., where thecustomer desires the DNS server to be within the customer's domain name)a set of IP addresses (e.g., 8 IP addresses) may be randomly selectedper protocol from the list of pool addresses and used for[a-h].ns.<customer domain>.

For off-net DNS servers, additional control over BGP communities andpaths may be included and addresses may be announced in a differentmanner. For example, a different abstraction may be implemented for thepool IPs in which the pool IPs are grouped into groups of apredetermined size (e.g., groups of eight assuming 64 addresses total).For purposes of this disclosure, each of these groups is referred to asan “off-net prefix”.

In some instances, addresses and off-net prefixes may conform to certainrequirements. One requirement may be that each off-net prefix is to beassigned out of a single subnet. For example, each off-net prefixcontaining 8 individual addresses may need to be assigned out of asingle /24 or /48 subnet. In such an implementation, each off-net DNSnetwork will thus need 8 /24s or /48s. Another requirement may be thatno other addresses are to be used within a subnet with the exception ofself-IPs being able to be assigned from the subnets for on-net clusters.Each subnet may also need to be part of an announced aggregate on agiven autonomous system. In other words, a given subnet may not be theonly announcement covering a network. Each subnet may also need to beannounced by a corresponding autonomous system in all regions (includingall peers). Another requirement may be that the shorter prefix (larger)aggregates that include the subnets also must be announced by theautonomous system to all regions. This ensures reachability for adefault free zone customer of the DEC ISP who might filter certainsubnet announcements based on operator choices to limit propagation ofsuch announcements. Such customers may continue to see these aggregates,even if they don't see the particular subnets.

In addition to the requirements provided above, additional host flagsmay be used to implement off-net nameservers. For example, such hostflags may include: an “off-net” host flag for indicating that addressesneed to be handled in groups of predetermined sizes; a BGP communitieshost flag indicating which communities (which may include standardand/or extended communities) should be sent; a BGP prepend host flagindicating how many times an ASN should be pre-pended to anannouncement; and a BGP max prefixes host flag that stores a limit onthe number of prefixes that a given DNS server may support.

In certain implementations, no “preferred” anycast address may beassigned to off-net servers. The off-net server may also operate ongroups of a predetermined number of anycast addresses when deciding toshed or not to shed. For example, the off-net server may be configuredto shed 8 (or any other predetermined number) of addresses at once foreach “step” when addressing overloading or similar situations. Any“excluded” anycast addresses for a given metro may cause the entiresubnet to be excluded from announcements. Also, off-net server may, incertain implementations, be assigned a unique IP address within adedicated subnet which may be used to validate that BGP propagation isdone properly.

FIG. 8 is a block diagram illustrating an example of a computing deviceor computer system 800 which may be used in implementing the embodimentsof the components of the network disclosed above. For example, thecomputing system 800 of FIG. 8 may be one or more of the DNS serversdiscussed above. The computer system (system) includes one or moreprocessors 802-806. Processors 802-806 may include one or more internallevels of cache (not shown) and a bus controller or bus interface unitto direct interaction with the processor bus 812. Processor bus 812,also known as the host bus or the front side bus, may be used to couplethe processors 802-806 with the system interface 814. System interface814 may be connected to the processor bus 812 to interface othercomponents of the system 800 with the processor bus 812. For example,system interface 814 may include a memory controller 814 for interfacinga main memory 816 with the processor bus 812. The main memory 816typically includes one or more memory cards and a control circuit (notshown). System interface 814 may also include an input/output (I/O)interface 820 to interface one or more I/O bridges or I/O devices withthe processor bus 812. One or more I/O controllers and/or I/O devicesmay be connected with the I/O bus 826, such as I/O controller 828 andI/O device 830, as illustrated.

I/O device 830 may also include an input device (not shown), such as analphanumeric input device, including alphanumeric and other keys forcommunicating information and/or command selections to the processors802-806. Another type of user input device includes cursor control, suchas a mouse, a trackball, or cursor direction keys for communicatingdirection information and command selections to the processors 802-806and for controlling cursor movement on the display device.

System 800 may include a dynamic storage device, referred to as mainmemory 816, or a random access memory (RAM) or other computer-readabledevices coupled to the processor bus 812 for storing information andinstructions to be executed by the processors 802-806. Main memory 816also may be used for storing temporary variables or other intermediateinformation during execution of instructions by the processors 802-806.System 800 may include a read only memory (ROM) and/or other staticstorage device coupled to the processor bus 812 for storing staticinformation and instructions for the processors 802-806. The system setforth in FIG. 8 is but one possible example of a computer system thatmay employ or be configured in accordance with aspects of the presentdisclosure.

According to one embodiment, the above techniques may be performed bycomputer system 800 in response to processor 804 executing one or moresequences of one or more instructions contained in main memory 816.These instructions may be read into main memory 816 from anothermachine-readable medium, such as a storage device. Execution of thesequences of instructions contained in main memory 816 may causeprocessors 802-806 to perform the process steps described herein. Inalternative embodiments, circuitry may be used in place of or incombination with the software instructions. Thus, embodiments of thepresent disclosure may include both hardware and software components.

A machine readable medium includes any mechanism for storing ortransmitting information in a form (e.g., software, processingapplication) readable by a machine (e.g., a computer). Such media maytake the form of, but is not limited to, non-volatile media and volatilemedia and may include removable data storage media, non-removable datastorage media, and/or external storage devices made available via awired or wireless network architecture with such computer programproducts, including one or more database management products, web serverproducts, application server products, and/or other additional softwarecomponents. Examples of removable data storage media include CompactDisc Read-Only Memory (CD-ROM), Digital Versatile Disc Read-Only Memory(DVD-ROM), magneto-optical disks, flash drives, and the like. Examplesof non-removable data storage media include internal magnetic harddisks, SSDs, and the like. The one or more memory devices 606 mayinclude volatile memory (e.g., dynamic random access memory (DRAM),static random access memory (SRAM), etc.) and/or non-volatile memory(e.g., read-only memory (ROM), flash memory, etc.).

Computer program products containing mechanisms to effectuate thesystems and methods in accordance with the presently describedtechnology may reside in main memory 816, which may be referred to asmachine-readable media. It will be appreciated that machine-readablemedia may include any tangible non-transitory medium that is capable ofstoring or encoding instructions to perform any one or more of theoperations of the present disclosure for execution by a machine or thatis capable of storing or encoding data structures and/or modulesutilized by or associated with such instructions. Machine-readable mediamay include a single medium or multiple media (e.g., a centralized ordistributed database, and/or associated caches and servers) that storethe one or more executable instructions or data structures.

FIG. 9 is an alternate network design for utilizing one or more loadbalancer devices in a DNS architecture. In particular, the networkenvironment 900 includes a metro 922 with one or more routers (e.g.,router A 902 and router B 904) connected to a network 102. One or moreDNS servers 910-912 may be connected to router A 906 and one or more DNSservers 914-916 may be connected to router B 908 for responding to DNSrequests received through network 102. In this implementation, however,a load balancer device A 906 is in communication with router A 906 and aload balancer B 908 is in communication with router B 908 for performingthe load balancing features of the routers described in the embodimentsabove. Load balancers 906-908 may be user datagram protocol (UDP)-basedload balancer devices and may be implemented to support direct serverreturn. In this network configuration 900, packet flow into the DNSservers 910-916 coupled to the routers 902-904 is directed through oneof the two load balancers 906-908, while outflow (e.g., flow back to anISP resolver or other requesting device) may travel directly and bypassthe load balancers.

The load balancers 906-908 may be implemented in several ways. Forexample, in one implementation, the load balancers 906-908 may bededicated hardware devices designed for load balancing of TCP and UDPconnections. In other implementations, the load balancers 906-908 mayinstead be general-purpose devices. For instance, the load balancers maybe an edge router with layer 4/7 capability, general-purpose hardwarerunning load balancing software, or may utilize a kernel networktranslation with multiple destinations to facilitate load balancing.While these design options differ in the capability of monitoring theservice, all may perform a similar function that was provided by therouter in the load-balancer-less solution previously discussed.

In some implementations, the load balancers 906-908 may support directserver return (DSR) functionality such that, when a packet is receivedat the load balancer, the destination address for the packet may betransformed to be a unicast DNS address associated with a single DNSserver 910-916, and then resent with the source address unchanged. Thereceiving DNS server would therefore receive the packet with the sourceIP address still present in the source of the packet, allowing it to beused for rendezvous decisions. In such circumstances, the actual DNSanswer may be terminated on the load balancer device and, when the loadbalancer receives a DNS query, a DNS request is sent to the backend DNSservers. As a result, the request provided to the DNS servers wouldoriginate from the load balancer 906-908.

To support DSR, the DNS servers 910-916 may have one VIP addressassociated with each public DNS server IP address. Thus, a request thatis received by the load balancer 906-908 on a public DNS IP address Amay be transformed and sent to VIP address A on DNS server X (the “VIP”in this case will merely be a unique destination port). A requestreceived by the load balancer 906-908 for public DNS IP address B wouldgo to a different VIP (port in this case) on DNS server X. Thus, ifthere are four public DNS addresses, there would be four DNS VIPs(ports) configured on each backend DNS server 910-916. In addition, theDNS operations may understand that when a request comes in on VIP A, itmay be answered with a source IP address of public DNS IP address A. Forexample, assume that the load balancer A 906 selects DNS server A 910from all available servers as the server to answer the DNS request.Packet flow within such a system may occur in accordance with the belowtable:

Translated into new Reply packet from Sent from ISP packet on loadbalancer DNS server to ISP Source <ISP addr>: <ISP addr>: <LB addr>:<ISP port 1> <ISP port 1> <LB port 2> Destination <LB addr>: <DNS addr>:<ISP addr>: <LB port 1> <DNS port 1> <ISP port 2>

In this network configuration 900, the load balancer A 906 translatesthe packet to an intermediate format. The DNS server 910 generally isinformed of the actual address to use to answer the DNS request.

Monitoring of servers 910-916 in the network configuration 900 thatincludes \load balancers 906-908 may include health checks be sent viathe load balancer 906-908 to a specific nameserver such that that thecomplete network path to/from the nameserver can be monitored. Forexample, should restrictive reverse path forwarding (RPF) be enabled onthe router 902, some packets may be dropped even if the unicast addressof the server was still reachable. Such monitoring may be performed insubstantially the same way proposed for the non-load-balancer solutionabove, with an anycast VIP (announced by the load balancer 906) assignedto a specific nameserver host for monitoring purposes. Further, in someimplementations of network environment 900, a predetermined number ofdistinct public IP addresses for each of IPv4 and IPv6 may be used fordelegation by global top level domain servers. For example, eight suchaddresses may generally allow for a balance between complexity andsufficient granularity to engage in traffic engineering if requiredduring periods of high load.

One advantage of implementing a load balancer 906 in the networkconfiguration 900 is that it may allow computing devices within adatacenter to function as part of a larger DNS cluster. In particular,all backend machines for a given anycast VIP on the load balancer 906may also be within a single datacenter to facilitate interaction withISP resolver statistical tracking (used by ISP resolvers to select whichauthoritative resolvers will answer a request). However, a second VIP onthe load balancer may point at other resolvers. These other resolversmay each be within a single datacenter, which may be a differentdatacenter than that associated with the first VIP so long as all thebackends for a given VIP are within a single datacenter. The public IPsmay be split into a predetermined number of “pools”. For example, in oneimplementation, the public IPs may be split into four pools. Within anysingle metro, only a subset of the pools may be advertised. So, forexample, if four pools exist, up to three pools may be advertised. Bydoing so, the issue where a datacenter blackholes all traffic causesunrelated outages. Also, each pool will have two IP addresses associatedwith it under normal circumstances.

In certain implementations, each pool may be associated with at leastone back end server and no backend server may be associated with morethan one pool in order to minimize impact should a server blackholetraffic. These pool backend servers may be configured as tier-1 serversin the load balancer. Handling of overloaded backend servers describedbelow in further detail. Should all backend servers associated with apool become unavailable, tier-2 and, if necessary, tier-3 servers may beutilized. Tier-2 servers may correspond with backend servers associatedwith the same pool address located in another datacenter (e.g., a majordatacenter nearby) while tier-3 servers may consist of all serverswithin a pool globally. In one example, each load balancer 906-908 of ametro 922 may be allocated to the pools as either the “ODD” or “EVEN”load balancer. The ODD/EVEN distinction refers to which of the twoaddresses associated with a pool is announced by the load balancer asprimary addresses. Two example ways this can be accomplished are: (1)modifying BGP export policies on a route reflector; and (2) implementingheartbeat monitoring. For modifying BGP export policies, the routereflector may accept multi-exit discriminators (MEDs) from the edgerouters associated with itself, but may reset those MEDs when exportingroutes. Each load balancer would may announce all addresses (ODD andEVEN, in the example) for its' associated pools. However, thenon-preferred addresses (e.g., EVEN addresses on an ODD balancer) may beannounced with a higher MED. For instance, preferred addresses may beannounced with a MED of 0 while non-preferred addresses may be announcedwith a MED of 500. When exporting the routes off of the route reflector,the MEDs for these routes may be reset to 0. Doing so may keep failoverlocal within the metro for a failed load balancer, and provide fairlyseamless failover without significant service interruption. Implementingheartbeat monitoring may include an outside process to reconfigure theBGP announcements on the load balancer when a corresponding load balance“mate” goes offline. To accomplish this, each load balancer mayadvertise its preferred addresses along with an IP address uniquelyassociated with that load balancer. Should the unique IP becomeunreachable from the other load balancer, the other load balancer maybegin to advertise the non-preferred addresses in addition to thepreferred addresses.

Denial of service attacks are a persistent threat against the DNSenvironment and can lead to load-related outages. Accordingly, it isoften desirable to have the ability to utilize all servers, world-wide,in the event of a major attack in order to “sink” traffic related to theattack. To address overloading (whether caused by an attack or otherevent), each backend DNS server may report load and each load balancermay independently gather the reported load information. The loadinformation may indicate the “shed factor” of the backend server, andmay be calculated the same way as is used in the previously discussedimplementation of this disclosure. The shed value may be used to weightservers within a tier on each load balancer. For example, a serverreporting needing to shed 20% of traffic may be assigned a weight of0.8. As long as the weight of at least one server in a tier remains 1,the server functions within the tier. Should a tier need to shed to thenext tier, the servers of the next tier may be temporarily added to thecurrent tier level, with weights appropriate to pull the amount oftraffic necessary to reduce the load on the other machines within thattier. The redistribution algorithm may also consider whether a serverhas excess capacity, and may not simply send traffic to a server thatmay not have excess capacity. In this manner, traffic could bedistributed among all servers throughout the world as necessary. Incertain implementations, once shedding to Tier 3 begins no attempt maybe made to provide low latency responses preferentially, although Tier2/Tier 3 may only receive the requests Tier 1 could not handle on its'own.

In certain implementations, the foregoing functionality may includeproviding certain additional information to each of the DNS servers.Such information may include, without limitation, new host flags for theDNS servers, new host types and flags for the load balancers, and newglobal configuration information that may be maintained, for example, ina configuration table. New host flags for the DNS servers may include apool name. New host types and flags for the load balancers may includeassociations between DNS networks, a role (e.g., the EVEN or ODDassignment discussed in the foregoing example), a monitoring address(also referred to herein as a “sentinel address” or “sentinel IP”), apeer IP, a self ASN, and a peer ASN. New global configuration data mayinclude a list of pools and associated public IP addresses as well asports associated with such pools. Such information may be maintained incertain implementations by a central computing system and distributed or“pushed out” to devices within the network (e.g., DNS servers and loadbalancers). Also, to the extent any of the information includes addressinformation, such address information may be maintained for multipleprotocols (e.g., IPv4 and IPv6).

Any suitable number of pools may be implemented in the DNS architecture208, with each including a suitable number of anycast addresses. Forexample, in one implementation, the system may include four pools(labeled A, B, C, D, for example) with each pool consisting of twoanycast addresses. Addresses may be chosen such that they are advertisedby two or more separate subnets to peers/customers. Each DNS network mayhave its' own idea of pools, but the names for such pools may be reused.In certain implementations, the system may throw an alarm on if allpossible pools exist in any metro 922, i.e., if host table entries existsuch that all pools are present for a given DNS network. Also, incertain implementations, each group (or first DNS machine on a router)may be assigned a unique “preferred pool” address, which may be assignedfor each of IPv4 and IPv6. This can be any pool address not used byanother group as a pool IP. It should be appreciated that there is nolimit on the number of machines within a pool within a metro 922 (orglobally).

In certain implementations, availability of backends may be monitored bythe load balancer software directly. Also, each load balancer mayimplement an algorithm to adjust weights and determine what to announce.For example, FIG. 10 illustrates a method 1000 for a load balancer toactively monitor each of the other load balancers in a metro 922 orgroup. The method 1000 provides a mechanism to utilize all DNS serversunder extreme load scenarios and enables the previously discussedfunctionality of the load balancers with limited sharing of statebetween machines. In general, the operations of the method 1000 may beperformed by a load balancer, such as load balancer A 906 of network900.

Beginning in operation 1002, the load balancer 906 may determine if atarget DNS server is drained. If the server is drained, the loadbalancer 906 may withdraw all announced addresses except the unique IPaddress in operation 1004, similar as described above. If the DNS serveris not drained, the load balancer 906 may announce the group preferredanycast address in operation 1006, also similar to as described above.In operation 1008, the load balancer may BGP announce those tiers withinthe servers in the metro 922 with a preferred role. In operation 1010,the load balancer 906 may determine if another load balancer in themetro 922 is up and operational. If not, the load balancer 906 may BGPannounce tiers with servers in the metro 922 with a backup role.

If the other load balancer is operational or the load balancer 906announces the tiers for the backup role, the load balancer 906 may builda list of tiered servers in operation 1014 while excluding those serversin a drain state in operation 1016. In operation 1018, the load balancer906 may set an initial weight of 1 for all in-tier servers and aninitial weight of 0 for all out-of-tier servers. In operation 1020, theload balancer 906 may apply a shed algorithm to lower weights foroverloaded servers and, in operation 1022, to redistribute removedweights. The load balancer 906 may then return to operation 1002 torepeat the loop.

The shed algorithm may, in some instances, be tuned to shed relativelyquickly but un-shed relatively slowly. For example, if load is high fora minute, start shedding but require load to be low for five minutes togain traffic back. In certain implementations, the shed algorithm mayattempt to estimate capacity. For example, CPU utilization of the DNSserver may be the primary factor in deciding whether to shed traffic.So, if CPU utilization is at 90% and a threshold of 80% utilization isapplied, 1/9 (i.e. 11.1%) of the IP addresses for the DNS server may beshed. Conversely, the quantity of shed IP addresses may be reduced ifloading of the DNS server falls after an initial shedding operation. Forexample and using the same 80% utilization threshold, if the load fallsto only 20% and 90% of IP addresses are have been shed by the DNS server(i.e., 10% of all IP addresses result in 20% loading), the percentage ofshed addresses may be reduced to 60% of all IP addresses. In certainimplementations, the method 1000 may be executed at regular periodicintervals (e.g., every minute).

To translate an address of a received packet, the load balancer maydetermine a destination server's unicast address, determine adestination server port, preserve the source address of the packet in adatagram, and retransmit UDP datagram with the translated destination.In this implementation, a packet is resent by the load balancer but to adifferent destination and the source (e.g., the ISP resolver) willremain unchanged. Address translation on the receiving DNS server mayinclude determining if the packet is sent to a pool UDP port number. Ifno, the server may respond to the packet without a translation. If yes,however, the server may set an answer packet source IP address to thepool public IP address and source port and transmit the answer packetwith that translation.

In some implementations with the load balancer, each DNS server maymonitor reachability and functionality of all public IPs, and may alarmif unreachable IPs are identified. The monitoring/sentinel IP of theload balancer may also be configured with multiple ports listening, eachpointing at a different individual server as the backend server. Thesemay also be tested to allow full path validation that can be localizedto the appropriate path. It should be noted that the responses in suchcases will come from the pool address associated with the backend DNSserver and not the monitoring/sentinel IP address.

Embodiments of the present disclosure include various steps, which aredescribed in this specification. The steps may be performed by hardwarecomponents or may be embodied in machine-executable instructions, whichmay be used to cause a general-purpose or special-purpose processorprogrammed with the instructions to perform the steps. Alternatively,the steps may be performed by a combination of hardware, software and/orfirmware.

Various modifications and additions can be made to the exemplaryembodiments discussed without departing from the scope of the presentinvention. For example, while the embodiments described above refer toparticular features, the scope of this invention also includesembodiments having different combinations of features and embodimentsthat do not include all of the described features. Accordingly, thescope of the present invention is intended to embrace all suchalternatives, modifications, and variations together with allequivalents thereof.

We claim:
 1. A method for processing domain name system (DNS) requests,the method comprising: announcing, by a DNS server and based on aconfiguration of the DNS server, a subset of a plurality of anycastInternet Protocol (IP) addresses associated with a DNS network, the DNSserver configured to receive a DNS request comprising at least one ofthe subset of the plurality of anycast IP addresses; receiving, at theDNS server and from a networking device, the DNS request comprising theat least one of the subset of the plurality of anycast IP addresses; andgenerating a response to the DNS request.
 2. The method of claim 1,further comprising: determining a number of a plurality of DNS serversof the DNS network; executing a hash function to slice the plurality ofanycast IP addresses based on the number of the plurality of DNS serversof the DNS network, wherein a result of the hash function identifies thesubset of the plurality of anycast IP addresses announced by the DNSserver.
 3. The method of claim 2, further comprising: load balancing aplurality of DNS requests to the DNS server based on the subset of theplurality of anycast IP addresses announced by the DNS server.
 4. Themethod of claim 1, further comprising: receiving, from a DNS controller,an identification of the subset of the plurality of anycast IPaddresses.
 5. The method of claim 1, further comprising: announcing, bythe DNS server to the networking device and in addition to announcingthe subset of the plurality of anycast IP addresses, a uniqueidentification address associated with the DNS server.
 6. The method ofclaim 5, further comprising: monitoring for announcement of a pluralityof unique identifications from a subset of a plurality of DNS servers;and generating an error message in response to receiving less than allof the plurality of unique identifications from a subset of theplurality of DNS servers.
 7. The method of claim 1, further comprising:removing, based on an overload condition at the DNS server, one or moreanycast IP addresses from the announced subset of the plurality ofanycast IP addresses to redirect additional DNS requests associated withthe removed one or more anycast IP addresses to another DNS server ofthe DNS network.
 8. The method of claim 7, further comprising: receivinga preferred anycast IP address of the plurality of anycast IP addresses,the preferred anycast IP address unique to the networking device incommunication with the DNS server; and announcing the preferred anycastIP address during an overload condition at the DNS server.
 9. The methodof claim 1, wherein the DNS network comprises a first metro network anda second metro network, the method further comprising: redirecting,based on an overload condition at a first DNS server of the first metronetwork, a plurality of DNS requests to a second DNS server of thesecond metro by ceasing announcement of at least one anycast IP addressat the first DNS server.
 10. A domain name system (DNS) architecturecomprising: a networking device; and a DNS server in communication withthe networking device, the DNS server configured to: announce, based ona configuration of the DNS server, a subset of a plurality of anycastInternet Protocol (IP) addresses associated with the DNS architecture towhich one or more DNS requests for the DNS architecture are addressed;receive, from the networking device and based on at least one of theannounced subset of the plurality of anycast IP addresses, a DNS requestcomprising the at least one of the announced subset of the plurality ofanycast IP addresses; and generate a response to the DNS request. 11.The domain name system of claim 10, further comprising: at least oneload balancer in communication with the networking device, the at leastone load balancer configured to load balance a plurality of DNS requeststo a plurality of DNS servers.
 12. The domain name system of claim 10,wherein the at least one of the plurality of DNS servers is furtherconfigured to executing a hash function to slice the plurality ofanycast IP addresses based on a number of a plurality of DNS servers ofthe DNS network, wherein a result of the hash function identifies thesubset of the plurality of anycast IP addresses announced by the DNSserver.
 13. The domain name system of claim 10, further comprising: acontroller configured to transmit an identification of the subset of theplurality of anycast IP addresses to the at least one of a plurality ofDNS servers.
 14. The domain name system of claim 10, wherein the DNSserver is further configured to: receive a unique identification addressassociated with a second DNS server; and determine, based on the uniqueidentification address associated with the second DNS server, anoperating state of the second DNS server.
 15. The domain name system ofclaim 10, wherein the DNS server is further configured to: remove, basedon an overload condition at the DNS server, one or more anycast IPaddresses from the announced subset of the plurality of anycast IPaddresses to redirect additional DNS requests associated with theremoved one or more anycast IP addresses to redirect additional DNSrequests associated with the removed one or more anycast IP addresses toanother DNS server.
 16. The domain name system of claim 15, wherein thenetworking device is associated with a preferred anycast IP address fromthe plurality of anycast IP addresses, the DNS server connected to thenetworking device announcing the preferred anycast IP address during anoverload condition at the DNS server.